Embodiments relate generally to data storage environments, and, more particularly, to auto-tiering of file systems in data storage systems within a common resource pool.
Many types of storage devices are available for storing data, each type having an associated cost, access speed, reliability, etc. Multiple storage devices of the same or different types can be provided as a resource pool, which may be managed as a storage system in which logical storage units can be identified by logical unit numbers (LUNs). The LUNs are often used to store file systems, which are typically collections of data relating to an application or group of applications. Notably, different types of file system data, even within a single file system, may be accesses frequently or infrequently, sequentially or non-sequentially, or in other ways. As such, optimizing a storage system (e.g., cost, throughput, etc.) can involve allocating appropriate amounts of appropriate types of LUNs to a file system.
One traditional approach is to choose a single, best type of LUN to use for storing file system data, accounting for trade-offs between various LUN metrics. Different types of storage can only be exploited by swapping out one or more of the original LUNs with a different type of LUN and moving some or all of the file system data. Another traditional approach is to choose two or more types of LUN, categorized into two or more storage classes, and to store different portions of the file system in those different storage classes. This approach allows exploitation of different storage types, but only through manual movement of the data between the storage classes and typically only within fixed LUNs (or partitions of LUNs) allocated to the particular file system.
For example, a data storage system is commonly used to store multiple file systems concurrently, and that each file system is guaranteed a certain capacity. That capacity can be ensured by selecting a subset of available LUNs in the storage system, or by generating fixed partitions within LUNs, to associate with each file system. All file system data is stored only on those LUNs and/or partitions, and those LUNs and/or partitions provide at least the guaranteed capacity. In this type of environment, data can be promoted or demoted between storage classes only through very coarse, manual operations, such as by moving an entire file system to a new LUN or by swapping out an entire LUN.
More recently, auto-tiering approaches became available. As with the preceding approach, a system administrator selects LUNs or partitions within LUNs as a priori resource allocations for file systems. A storage manager is used to monitor usage by the file systems of their respective allocated resources (e.g., data blocks). The storage manager can move file system data to data blocks of different storage classes within the file system's allocated resources. For example, some systems always store new data by default to the most expensive storage class, and the data can be promoted or demoted over time depending on how often and/or in what manner the data is accessed. Other systems initially store data according to an a priori quality of service characterization of the file system or the file system data (e.g., by the system administrator) and move the data, as needed, to optimize performance. While these auto-tiering techniques can appreciably improve performance of many file systems, they are still limited in a number of ways. For example, many such systems can promote or demote data only within the a priori allocations associated with a file system, only at the LUN level, etc.